home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-chang-iimc-proxy-00.txt
< prev
next >
Wrap
Text File
|
1993-03-03
|
93KB
|
2,168 lines
INTERNET DRAFT Expires April 23, 1993
ISO/CCITT and Internet Management Coexistence (IIMC):
ISO/CCITT to Internet Management Proxy
(IIMCPROXY)
October 9, 1992
April Chang
NetLabs, Inc
4920 El Camino Real
Los Altos, CA 94022
april_chang@netlabs.com
Status of this Memo
This memo provides information to the network and systems
management community. This memo is not proposed to be a
standard, but is intended as a contribution to ongoing work
in the area of multi-protocol management coexistence and
interworking. This memo is part of a package of ISO/CCITT
and Internet Management Coexistence (IIMC) drafts; see also
[IIMCIMIBTRANS], [IIMCIMIB-II], [IIMCPARTY], and
[IIMCOMIBTRANS].
This document is an Internet Draft. Internet Drafts are
working documents of the Internet Engineering Task Force
(IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet
Drafts.
Internet Drafts are draft documents valid for a maximum of
six months. Internet Drafts may be updated, replaced, or
obsoleted by other documents at any time. It is not
appropriate to use Internet Drafts as reference material or
to cite them other than as a "working draft" or "work in
progress".
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil,
nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, munnari.oz.au
to learn the current status of any Internet Draft.
Distribution of this memo is unlimited. Comments on this
memo should be sent to iimc@thumper.bellcore.com by November
20, 1992.
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
Abstract
This memo is intended to facilitate the use of the OSI
Common Management Information Protocol (CMIP) for integrated
management of networks via proxy management of TCP/IP
networks that are managed using Simple Network Management
Protocol (SNMP). This memo describes a ISO/Internet "proxy"
which allows interworking between CMIP-based managers and
SNMP-based agents. The proxy emulates CMIS service requests
by mapping between corresponding ISO/CCITT GDMO and Internet
MIB definitions, and generating SNMP message(s) needed to
emulate the service. The proxy also emulates CMIS service
responses and notifications by converting incoming SNMP
response and trap message(s) in a similar fashion. Thus,
the proxy appears as a CMIP-based agent to the manager, and
as an SNMP-based manager to the agent. The proxy depends on
the availability of corresponding MIB definitions translated
as described in [OIMMIBTRANS].
Table of Contents
Status of this Memo ......................................i
Abstract .................................................ii
Table of Contents ........................................ii
1. Introduction ..........................................1
1.1. Background ..........................................1
1.2. Overview ............................................2
1.3. Scope ...............................................3
1.4. Terms and Conventions ...............................5
2. ISO/Internet Proxy Configuration ......................6
2.1. Schema Information ..................................6
2.2. Proxy Objects and Party Objects .....................6
2.3. Usage ...............................................8
3. Elements of CMISE Service Emulation ...................9
3.1. Association Service .................................9
3.2. Management Object Selection .........................10
3.3. Synchronization .....................................12
3.4. Management Operation Services .......................13
3.5. Management Notification Services ....................19
3.6. Common Response Parameter ...........................19
4. CMIP and SNMP Protocol Mapping ........................20
4.1. Management Object Selection .........................20
4.2. Check for Existence of the Object ...................21
4.3. Create With Referenced Object .......................23
4.4. Perform the Get Operation ...........................23
4.5. Perform the Set Operation ...........................23
4.6. Perform the Create Operation ........................23
4.7. Perform the Delete Operation ........................24
4.8. Form a Variable Binding .............................24
4.9. SNMP error to CMIP error mapping ....................25
5. CMIP Processing Failure ...............................26
6. Functional Units ......................................27
7. Abbreviations .........................................28
Chang Page ii
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
8. Acknowledgements ......................................28
Appendix A: CMIP to RFC 1157 Agent proxy .................29
Appendix B: Example Operation ............................31
Chang Page iii
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
1. Introduction
1.1. Background
This memo is part of a package of ISO/CCITT and Internet
Management Coexistence (IIMC) drafts. Other memos included
in this package are:
-Translation of Internet MIBs to ISO/CCITT GDMO MIBs
(LaBarre) [IIMCIMIBTRANS]
-Translation of ISO/CCITT GDMO MIBs to Internet MIBs
(Newnan) [IIMCOMIBTRANS]
-Translation of Internet MIB-II (RFC1213) to ISO/CCITT
GDMO MIB (LaBarre) [IIMCMIB-II]
-Translation of Internet Party MIB (RFC1353) to ISO/CCITT
GDMO MIB (LaBarre) [IIMCPARTY]
These memos together comprise a package aimed at integrating
ISO/CCITT-based and Internet-based management systems.
These memos are offered as input to coexistence and
interworking efforts underway throughout the
industry,including organizations such as:
- IETF OSI Internet Management (OIM),
- Network Management Forum Technology Convergence Team,
- X/Open Systems Management (SysMan),
- OIW Network Management Special Interest Group (NMSIG),
and
- OSF Management Special Interest Group (MANSIG).
This work was initiated, in part, by NM Forum efforts to
translate RFC 1214 for use with OMNIPoint 1 implementations.
Through this effort, it became obvious that end-to-end
management requires an integrated, unified view of the
managed network, despite differences in management protocol
and information structure. Integrated management can be
facilitated by the development of "proxy" mechanisms which
translate between functionally equivalent service, protocol,
and SMI differences to create this unified view. MIB
translation procedures can be used to support proxy
management, as well as to take advantage of existing MIB
definition and avoid duplication of effort. In this way,
commercial investment in both ISO/CCITT and Internet-based
management technologies can be preserved through deployment
of common methods and tools which support integration.
This overall strategy was outlined in a joint publication
developed by the NM Forum and X/Open entitled "ISO/CCITT and
Internet Management: Coexistence and Interworking Strategy"
[NMFMC92]. The memos included in the IIMC package are
intended as detailed specifications which implement several
of the methodologies identified in this strategy.
Chang Page 1
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
1.2. Overview
The basic model for ISO/CCITT-Internet proxy management is
illustrated in the following diagram.
Manager Proxy Agent
+-----------------+ +----------------+ +-------------------+
|+---------------+| |+----++--------+| | +---------------+ |
|| Management || ||GDMO||Internet|| | | Managed | |
|| Applications || ||MIB || MIB || | | Resources | |
|+---------------+| |+----++--------+| | +---------------+ |
| | | |+--------------+| | | |
| | | || Service || | | |
| | | || Emulation || | | |
| | | ||(scoping) || | | |
| | | || (filtering) || | | |
| | | || (operations)|| | | |
|+---------+-----+| |+--------------+| |+--------+--------+|
||ISO/CCITT|GDMO || || Map Protocols | ||Internet|Internet||
|| Manager |MIB || ||CMIS| |SNMP|| || Agent | MIB ||
|+---------+-----+| |+----+----+----+| |+--------+--------+|
| | | | |CMIS | | | | |
| |CMIS Services| | |Services | | | |SNMP "Services"|
| | | | | | | | | |
| | | | | SNMP| | | | |
| | | | |"Services"| | | | |
+-----------------+ +----------------+ +-------------------+
| CMIP | | CMIP | SNMP | | SNMP |
+-----------------+ +----------------+ +-------------------+
^ ^ ^ ^
| | | |
+---------------+ +---------------+
CMIP Messages SNMP Messages
The proxy architecture provides emulation of CMIS services
by mapping to the corresponding SNMP message(s) necessary to
carry out the service request. The service emulation allows
management of Internet objects by an ISO/CCITT manager. The
left hand side of the proxy behaves like an ISO/CCITT agent,
communicating with the ISO/CCITT manager using CMIP
protocols. The right hand side of the proxy behaves like
an Internet manager, communicating with the Internet agent
using SNMP protocols.
The proxy relies on the existence of a pair of directly-
related MIB definitions, where the Internet MIB has been
translated into ISO/CCITT GDMO using the procedures
specified in [OIMMIBTRANS]. The proxy defined in this memo
uses these MIB definitions and rules to provide run-time
translation of management information carried in service
requests and responses.
Chang Page 2
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
The proxy architecture is designed with a specified
interface between the proxy and the underlying protocol
stacks, and so deals primarily in terms of CMIS services and
SNMP "services". The proxy emulates services such as CMIS
scoping and filtering, processing of CMIS operations, and
forwarding/logging of CMIS notifications by performing a
mapping process which must be tailored for each protocol
(for example, SNMP, Secure SNMP, and SNMP-2 are all variants
of the same protocol mapping process).
Finally, [IIMCOMIBTRANS] specifies translation procedures
for converting ISO/CCITT GDMO MIBs into Internet MIBs. MIBs
generated by this translation process cannot be utilized by
the Proxy defined in this memo, although another kind of
Proxy could be defined for this purpose in the future.
1.3. Scope
The intent of the memo is to facilitate the use of CMIP to
perform integrated management of networks via proxy
management networks that are managed using SNMP. There are
two major differences between the CMISE and SNMP services:
one is the object model; and the other is the operations
supported by the protocols. The ISO/Internet proxy
architecture as shown in the above picture provides the
CMISE service emulation. In another words, the ISO/Internet
proxy acts as a CMIP agent with respect to the CMIP manager,
allowing management of Internet objects by the ISO/CCITT
manager. The CMIP requests would be processed by the
ISO/Internet proxy and CMIP responses would be returned by
the ISO/Internet proxy. SNMP traps would be converted to
CMIP notifications by the ISO/Internet proxy. The
implementation of the CMISE service emulation requires that
a mapping exist between ISO/CCITT objects and Internet
objects. There are different approaches that can be used to
map between Internet objects and ISO/CCITT objects.
1) Direct Translation
2) Abstract Translation
The direct translation approach maps each Internet object to
a newly defined ISO/CCITT object that contains: 1) the same
information as contained in the Internet object; and 2) the
attributes that are inherited from the ISO/CCITT Top object
class.
The abstract approach maps the Internet objects to
previously defined ISO/CCITT objects. For example, the MIB-
II system object could be represented by the ISO/CCITT
system object. No new object classes or attributes are
needed with this approach.
Either or both approaches could be used by a ISO/CCITT
manager to manage Internet agents. However, a large number
Chang Page 3
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
of Internet MIBs have been defined by the Internet community
using the Internet SMI [RFC1155] and it is quite possible
that there is no equivalent ISO/CCITT objects defined for
some of the Internet MIBs at this point of time. For
example, an Internet object and an ISO/CCITT object might be
defined by different groups, and the attributes in the two
objects could be significantly different. The mapping
between the two objects could be very difficult, if it not
impossible to perform.
This memo uses the "direct translation" approach".
To perform the CMISE service emulation, the ISO/Internet
proxy can use either of the following two approaches to
retrieve or modify Internet MIB information:
1. State-less approach
2. Stateful approach
The state-less approach would not maintain the Internet
agent's MIB data. For each CMIP request, the ISO/Internet
proxy would perform one or more SNMP requests.
The stateful approach would be to replicate the proxied
agent's MIB data. The ISO/Internet proxy would replicate
the Internet agent's MIB data locally. For each CMIP
request, the ISO/Internet proxy would fulfill the request
using data in its own local copy of the Internet MIBs.
The stateful approach will usually provide better response
time, but has the drawback that the data retrived might not
be up to date. This approach also requires a data
synchronization mechanism between the ISO/Internet proxy and
the proxied Internet agents. The frequency at which the MIB
data in the ISO/Internet proxy is updated would have a
significant effect on the accuracy of the response.
This memo uses the first approach. With that approach the
ISO/Internet proxy performs the following operations:
translation of CMIP requests to SNMP requests; translation
of SNMP responses to CMIP responses; and translation of SNMP
traps to CMIP notifications.
If necessary, the Internet MIB data retrived by the
ISO/Internet proxy could be cached by the proxy in order to
increase the response time of an operation. This memo makes
no assumption that the proxy is maintaining any state
information, and so takes no advantage of information which
might be cashed.
This memo describes a protocol mapping process based on the
IS CMIP (ISO/IEC 9596-2;1991) and on secure SNMP (RFC 1351 -
RFC 1353). A protocol mapping process based on IS CMIP and
RFC 1157 SNMP would be slightly different from the IS CMIP
Chang Page 4
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
to secure SNMP mapping process. These differences are
described in Appendix A of this memo.
This memo assumes that the the CMIP PDU and SNMP PDU
received by the ISO/Internet proxy are always properly
encoded. The uderlying protocol providers should ensure the
correctness of the service indications and confirmations
that are passed up to the ISO/Internet proxy.
1.4. Terms and Conventions
1.4.1 ISO/CCITT manager: An application entity that
implements ISO/IEC 9596-2;1991.
1.4.2 Internet agent: An application entity that is
conformant to RFC 1352.
1.4.3 ISO/Internet Proxy: An application entity that is
responsible of mapping CMIP requests to SNMP
requests, SNMP responses to CMIP responses, and SNMP
traps to CMIP notifications among any number of
ISO/CCITT managers and Internet agents.
1.4.4 Known Internet agents: A set of one or more Internet
agents that a ISO/Internet proxy has knowledge of.
The known Internet agents could be represented by
proxy object instances. The SNMP proxy object class
is defined in [OIMTRANSMIB].
1.4.5 Known SNMP Parties: A set of one or more SNMP parties
that a ISO/Internet proxy has knowledge of. The
known SNMP parties could be represented by the SNMP
party object instances. The SNMP party Object is
defined in [OIMPARTY].
1.4.6 Pseudo Object: A CMIP object class that represents an
SNMP group. The pseudo object does not contain any
SNMP attributes. For example: a CMIP object that
represents "at" in MIB-II, or any CMIP objects
representing SNMP tables.
1.4.7 Access Policy: The SNMP version and the security
policy.
1.4.8 Multiple Instance Object: An object class that may
have more than one object instance. For example,
SNMP table entries.
1.4.9 Delete Information: Delete information is the object
identifier of the attribute and its attribute value
used to indicate a particular row of a table is
deleted.
Chang Page 5
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
2. ISO/Internet Proxy Configuration
In order for the ISO/Internet proxy to access each proxied
Internet agent, and to access the proxied agents using the
appropriate transport and network address, and using the
appropriate access policy, the ISO/Internet proxy is
required to have some knowledge about the proxied Internet
agents.
2.1. Schema Information
To perform CMISE service emulation, the ISO/Internet proxy
requires schema information for all of the Internet MIB
definitions supported by a proxied agent. The schema
information could be described to the ISO/Internet proxy
using ISO/CCITT GDMO. Name binding definitions and matching
rules are required if scoping and filtering are supported.
The name binding definitions are needed to perform scoping
and the matching rules are needed to perform filtering.
A translation procedure for converting Internet MIB and
Internet trap definitions into corresponding ISO/CCITT GDMO
definitions is described in [OIMMIBTRANS]. The proxy
describes in this memo requires as input the schema
information for any Internet MIB translated to ISO/CCITT
GDMO format using the [OIMMIBTRANS] procedures.
The ISO/CCITT GDMO definitions based on RFC [OIMTRANSMIB]
provide the object class, attribute, attribute syntax, name
binding, and notification definitions. If the ISO/CCITT
object class maps to an SNMP table entry, the behaviour
clause (as defined in 3.3.1 of [OIMTRANSMIB] would describe
the following information that is required by the
ISO/Internet proxy:
a) the attributes that form the object instance;
b) whether or not the object is a multiple instance
object (as defined in section 2.8 of this memo);
and
c) if the object is a multiple instance object, the
delete information for the object (as defined in
section 2.9 of this memo).
2.2. Proxy Objects and Party Objects
RFC [OIMPARTY] defines some local object classes that are
required by the ISO/Internet proxy to perform the CMISE
service emulation.
The ISO/Internet proxy requires the following instances of
the local object classes for each proxied Internet agent:
- one "cmipsxmpProxyEntry" object instance
- one "partyTable" object instance
Chang Page 6
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
- one or more "partyEntry" object instances
This memo refers to the above object instances as "local
objects" or as "local object instances".
The "cmipsxmpProxyEntry" object instance contains the
proxied SNMP agent's name and serves as a containment
object. All the information related to a particular
Internet agent would exist below the "cmipsxmpProxyEntry" in
the managed information tree (MIT). This information
includes all the Internet MIB objects that belong to a
particular Internet agent and any configuration information
needed by the ISO/Internet proxy (such as a partyTable
object).
The "partyTable" object is the container object for all the
"partyEntry's". Only one "partyTable" object instance
should be created below the "cmipsxmpProxyEntry" object
instance.
The "partyEntry" object contains the proxied Internet
agent's address and the security mechanism used between the
ISO/Internet proxy (acting as Internet manager) and the
Internet agent. The security mechanism could either be an
SNMP 1157 community-based or a secure SNMP party-based
mechanism. A different "key" is stored in the "partyEntry"
object, based on the chosen security mechanism.
The information described in the preceding paragraphs must
be available to the ISO/Internet proxy before any CMIP
requests or SNMP traps can be processed by the ISO/Internet
proxy. The ISO/CCITT manager could provide this
configuration information to the ISO/Internet proxy by
sending M-Create requests to the ISO/Internet proxy in order
to create the proxy and party objects.
If the CMIP request to create an SNMP proxy object succeeds,
the ISO/Internet proxy adds the SNMP proxy object to its
list of known Internet agents. If the CMIP request to
create an SNMP party object succeeds, the ISO/Internet proxy
adds the SNMP party object to its list of known SNMP
parties.
It is the ISO/CCITT manager's responsibility to manage the
known Internet agents and known SNMP parties. CMIP requests
could be initiated by the ISO/CCITT manager to add, delete,
or modify elements in the known Internet agents and the
known SNMP parties.
2.3. Usage
The known Internet agents, and the known SNMP parties
provide the basis for the ISO/Internet proxy to perform the
following translation:
Chang Page 7
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
- Translating CMIP requests to SNMP requests
- Translating SNMP responses to CMIP responses
- Translating SNMP traps to CMIP notifications
In a CMIP request, the "cmipsxmpProxyEntry" object is
represented by one of the relative distinguished names (RDN)
that make up a distinguished name (DN). In the MIT, there
are one or more party objects contained under the
"cmipsxmpProxyEntry" object.
2.3.1. Security
Section 3.3.1.1 Section 3.3.1.2
| |
+-------------+ | +------------------+
|ISO/CCITT mgr|<--->|ISO/Internet Proxy|<---> Internet agent
+-------------+ +------------------+
2.3.1.1. The Security Policy between the ISO/CCITT manager
and the ISO/Internet Proxy
The information transferred between the ISO/CCITT manager
and the ISO/Internet proxy is protected by the security
policy between the ISO/CCITT manager and the ISO/Internet
proxy (acting as a CMIP agent). The security policy between
an ISO/CCITT manager and a CMIP agent is not part of the
scope of this memo.
2.3.1.2. The Security Policy between the ISO/Internet Proxy
and the Internet agent
The information transferred between the ISO/Internet proxy
and the Internet agent is protected by a security policy
between the ISO/Internet proxy and the Internet agent. In
order to minimize the network traffic between the
ISO/Internet proxy and the Internet agent, and also to
reduce the number of party objects, this security policy
should be enforced using the following two distinct steps:
2.3.1.2.1. Local Security Policy
First, a local security policy that maps a CMIP request to a
source party and a destination party based on the
distinguished name, the access control field; and possibly
the operation type and the attributes in the attribute list.
The security mapping process should be based on a local
security policy that is mutually agreed to and implemented
by the ISO/CCITT manager and ISO/Internet proxy. The local
security policy is not within the scope of this memo. A
separate memo to define this security policy may be produced
after the secure SNMP and SMP are finalized.
Chang Page 8
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
The ISO/Internet determines a pair of source party and
destination party contained in the "cmipsxmpProxyEntry"
object based on the DN, access control parameter, and
possibly the operation type, and attribute list. The method
of selecting the party pair is a local issue.
If this mapping step fails, the ISO/Internet proxy must send
an "access denied" error response back to the ISO/CCITT
manager. An SNMP request will not be generated by the
proxy.
2.3.2. Packaging SNMP Request
Second, if the previous step is successful, a source party
and a destination party are chosen as the basis for
packaging the SNMP request. The selected SNMP source party
and destination party specifies the SNMP protocol version
and the SNMP security protocol to use with the SNMP request
generated by the ISO/Internet Proxy.
SNMP request message should be encoded based on the secure
SNMP protocol using the selected source party and
destination party.
3. Elements of CMISE Service Emulation
The following sections describe the conceptual process for
performing CMIP service emulation. In an actual
implementation, it should be possible to combine some of the
processes. It is highly recommended that the implementor of
the ISO/Internet proxy combine the processes where possible
to to optimize the implementation. If the ISO/Internet
proxy needs to perform an SNMP request to fulfill a CMIP
request, the ISO/Internet protocol translation that would be
used to translate the request is described in section 4 of
this memo.
3.1. Association Service
The ISO/Internet proxy should provide the association
service defined in section 8.1 of ISO/IEC 9596-2;1991. This
service includes association establishment and association
release. Each CMIP request issued within the context of a
specific association, should only be performed if the
request specifies functional units negotiated for the
association.
3.2. Management Object Selection - Scoping and Filtering
Managed object selection is used to determine a set of
object instances in the MIT on which a CMIP request is to
operate. Managed object selection is performed in two
phases: scoping; and then, filtering. Scoping is used to
Chang Page 9
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
specify a sub-tree of object instances in the MIT. A filter
is then applied to the set of previously scoped object
instances in order to identify a subset of object instances
on which the CMIP operation is to be performed.
The scope specified in the CMIP request is applied to
determine a set of object instances against which a filter
(if specified) is to be applied. If no filter is specified
the CMIP request will be performed for all object instances
identified by the scope.
There are different ways of performing scoping operation.
This memo specifies one possible way of providing managed
object selection service.
3.2.1. Object Class Group
The following algorithm specifies a method of determining an
"object class group" that includes a set of object class
object identifiers. Each of the object instance within the
scope, is an instance of an object class that is in the
object class group.
The variables used in these steps are fictitious variables
used to control the process, not attributes or objects.
Step 1:
"current level" = 0
"current level object classes" = the base object specified
in the CMIP request
"next level object classes" is set to empty
"object class group" is set to empty
Step 2:
If the "current level" is greater than the maximum level
relative to the base object in the scope or the "current
level object classes" is empty, go to step 5.
Step 3.
If the "current level object classes" is empty, go to
step 4.
Take the first object class in the "current level object
classes". This object class is called "current object
class"
For all the known name bindings in the proxy's schema, if
the "NAMED BY SUPERIOR OBJECT CLASS" is equal to the
"current object class", the "SUBORDINATE OBJECT CLASS" is
added into "next level object classes".
Chang Page 10
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
If the current level is greater than the minimum level and
smaller than the maximum level in the scope, the
"SUBORDINATE OBJECT CLASS" is added into "object class
group".
Interate through step 3 again.
Step 4:
"current level object classes" = "next level object classes"
"next level object classes" is set to empty
bump up "current level" by one
Iterate through step 2 again.
Step 5:
If the "object class group" is empty, there is no object
instance selected by the scope. In this case, an empty
final CMIS response should be returned.
If the "object class group" is not empty, for each object
class in the "object class group", the following three steps
should be taken to retrieve the object instances in the
scope:
3.2.2. If the object class is a multiple instance object,
the first instance (.i.e., the first row in the table)
should be retrieved.
If the object class is not a multiple instance object,
retrieve the object instance of the object class.
3.2.3. If a filter is specified, apply the filter to the
retrived value. If the filter evaluates to FALSE, the CMIP
operation will not be performed for the object instance. If
the filter evaluates to TRUE, the operation will be
performed for the instance.
3.2.4. If the object instance is a multiple instance object,
retrieve succeeding instances (i.e., the succeeding rows in
the table). If a filter is specified, apply the filter as
specified in 5.2.2. Repeat this process until all instances
of the multiple instance object (i.e. all rows) have been
retrieved.
The scoping process could be highly optimized by local means
to retrieve information in multiple ISO/CCITT object
instances at once.
The filtering process should also be optimized where it is
applicable. For example, if the attribute in the filter
item does not exist according to the object class
definition, the ISO/Internet proxy should evaluate the
Chang Page 11
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
filter as FALSE without trying to retrieve the attribute
from the object instance. If the CMIP request is a get
request, the filter process described above may also be
combined with the retrieval of the attributes specified in
the attribute id list.
3.3. Synchronization
If the ISO/Internet proxy receives a CMIP "atomic" request,
but can not perform the operation atomically, the
"synchronization not supported" CMIP error response should
be returned to the ISO/CCITT manager.
The types of atomic requests that the ISO/Internet proxy can
perform are
as follows:
1) if all the instances selected by a scoped CMIP
request are "local object instances", then the
ISO/Internet proxy can perform the CMIP request
locally (and atomically); and
2) if all the CMIP request can be performed by the
ISO/Internet proxy using a single SNMP request, then
the operation can also be performed atomically.
For a "best effort" request, the ISO/Internet proxy should
try to perform the request on all the instances specified by
the request. In some cases, the CMIP request has to be
translated into multiple SNMP requests in order to fulfill
the original CMIP request. In the window in which these
SNMP requests are being processed, another SNMP set request
could be issued which could modify data in instances
specified by the scope. Because of this, the complete
integrity of the scoped request can not be guaranteed. A
proxy which complies with this memo is not required to
detect or avoid this situation, and will not usually report
any error if this situation occurs.
3.4. Management Operation Services
If the specified instances (i.e., those identified by
scoping and filtering specified in a CMIP request) are
"local object", the ISO/Internet proxy would perform the
services using local means. Instances of "partyTable", and
"partyEntry" are considered to be "local objects".
If the specified instances are "remote objects", then the
following sections apply. Any objects that physically
reside in the SNMP agents are considered as "remote
objects". For example, any MIB II objects like system, tcp,
and upd ate considered as "remote objects".
3.4.1. M-GET Service
Chang Page 12
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
The following sections describe how to provide M-GET
service.
3.4.1.1. Check the Existence of the Base Object
The existence of the ISO/CCITT base object specified in a
CMIP request should always be verified before scoping is
started. If the base object specified in the request does
not exist in the Internet agent, then the proxy must send a
"NoSuchObjectInstance" CMIP error response back to the
ISO/CCITT manager.
If the base object is a table entry or an SNMP group with at
least one Internet object type (i.e., not a pseudo object),
the ISO/Internet proxy should try to retrieve at least one
attribute of the base object from the SNMP agent to verify
the existence of the base object.
If the base object is a pseudo object, the ISO/Internet
proxy should try to retrieve at least one attribute from the
first subordinate object in the MIT that is not a pseudo
object, in order to verify the logical existence of the base
object (pseudo object).
3.4.1.2. Perform the Get Operation
If scoping or filtering is specified, the process described
in section 4.2 of this memo is used to select the ISO/CCITT
object instances. For each selected ISO/CCITT object
instance, all of the attributes specified in the "Attribute
identifier list" parameter of the CMIP request are
retrieved. If the "Attribute identifier list" parameter is
omitted, all attributes of the instance are of retrieved.
The list of attributes are in an object class are included
in the definition of the object class. It is recommeded
that the retrieval of the attributes be combined with the
retrieval of the attributes specified by the filter.
Section 5.4 describes the CMIP M-GET to SNMP get protocol
mapping.
3.4.1.3. Form the Response(s)
The CMIP M-GET response should contain the attribute value
list or the appropriate get list error. Once the M-GET
response has been formatted, it should be passed to the CMIP
service provider.
If the CMIP get request is a scoped request, each ISO/CCITT
object should be reported as link reply. a final empty CMIS
M-GET response should be returned to the ISO/CCITT manager
when the scoped request completes.
Chang Page 13
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
The managed object instance in the CMIP get response should
use the the distinguished name (DN) specified in the
original CMIP request as a prefix. The get responses for
subordinate objects below the base object in the naming
tree, should contain DN's that are formed from the
concatenation of the DN from the original CMIP request and
the RDN's specifying the table entry deleted.
3.4.2. M-CANCEL-GET Service
The CMIP cancel get operation should be performed as
described in ISO/IEC 9596. The ISO/Internet proxy does not
need to translate this request to any SNMP requests.
After receiving a cancel-get request message the
ISO/Internet proxy should terminate any outstanding
communications with the Internet agent that were initiated
as a result of the get request that is being canceled. Once
the cancel-get has been processed and responded to, the
ISO/Internet proxy should not send any additional response
messages to the ISO/CCITT manager for the get operation that
was canceled.
3.4.3. M-SET Service
The following sections describe how to provide M-SET
service.
3.4.3.1. Check the Existence of the Base Object
This operation is the same as described in section 4.4.1.1.
3.4.3.2. Scope and Filter
This operation is the same as described in section 4.4.1.2.
3.4.3.3. Perform the Set Operation
For each selected ISO/CCITT object instance, the attributes
specified in the "Modification list" parameter of the CMIP
request are modified based on each attribute's modify
operator. Only the "replace" modify operator is supported
by the ISO/Internet proxy. The modify operator is optional
and if it is not specified in a CMIP request, the "replace"
operator should be assumed.
The "add value" and "remove value" modify operators are not
supported by SNMP protocol, and are not supported by the
ISO/Internet proxy. The "set to default" modify operator is
not supported by the ISO/Internet proxy since the
ISO/Internet proxy is acting as an Internet manager. The
"set to default" behaviour is optionally implemented by the
Internet agent, not the Internet manager. If the modify
Chang Page 14
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
operator is not supported, "invalid operator" should be
reported in the set list error.
Section 5.5 of this memo describes the CMIP M-SET to SNMP
set protocol mapping.
3.4.3.4. Form the responses
The CMIP M-SET response should contain the attribute value
list or the appropriate set list error. Once the M-SET
response has been formatted, it should be passed to the CMIP
service provider.
If the CMIP set request is a scoped request, each ISO/CCITT
object should be reported as link reply. A final empty
CMISE M-SET response should be returned to the ISO/CCITT
manager when the scoped request completes.
The managed object instance in the CMIP set response should
use the the distinguished name (DN) specified in the
original CMIP request as a prefix. The set responses for
subordinate objects below the base object in the naming
tree, should contain DN's that are formed from the
concatenation of the DN from the original CMIP request and
the RDN's specifying the table entry deleted.
3.4.4. M-ACTION Service
The proxy is not required to emulate the CMIS M-ACTION
service because Internet MIBs do not include any definitions
which translate into M-ACTIONs in an ISO/CCITT GDMO MIB.
Any CMIS M-ACTION request which is received pertaining to an
Internet MIB object will be rejected by the proxy with an
invalidOperation error response. However, CMIS M-ACTION may
be used by the proxy for other purposes
3.4.5. M-CREATE Service
3.4.5.1. Request Validation
The ISO/Internet proxy is responsible for validating that
the CMIP create request does not violate name binding and
object class definitions.
3.4.5.1.1. Name Binding
The ISO/Internet proxy must determine from the CREATE
parameter in a name binding if an instance may be created.
If the instance cannot be created, an "access denied" error
response should be returned.
The ISO/Internet proxy must also determine from the name
binding if the instance specified in the request may be
created under the specified superior in the MIT. If the
Chang Page 15
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
name binding does not allow the specified containment
relationship, an "invalidOperation" error response should be
returned.
3.4.5.1.2. Check for Duplication
Determine if the instance already exists. If it does, a
"duplicate managed object instance"i error response should
be returned.
See 4.4.1.1. of this memo for checking the existence of an
object.
3.4.5.2. With Referenced Object
If a CMIP create request specifies a reference object, the
ISO/Internet proxy should retrieve the referenced object
from the Internet agent. If the reference object does not
exist, the proxy must send a "No such reference object"
error response back to the ISO/CCITT manager.
3.4.5.3. With Automatic Instance Naming
A CMIP create request can use automatic instance naming to
form a name for the object instance to be created.
Automatic instance naming is used if: a) a CMIP create
request does not specify a distinguished name for the object
instance to be created; and b) the request specifies an
object class that has a name binding allowing automatic
instance naming.
It is the responsibility of the ISO/Internet proxy to form
the name based on the behavior of the object class. In some
cases, the relative distinguished name (RDN) is formed using
attributes provided in the CMIP request. For example, the
RDN for "atEntry" in MIB-II could be formed from the
"atNetIfIndex" attribute and the "atNetAddress" attribute.
In other cases, the RDN can be assigned by the ISO/Internet
proxy.
If the superior object instance is not specified, the
ISO/Internet proxy can not create the object instance and
"processing failure" error should be returned.
3.4.5.4. Perform the Create Operation
If the combination of the attributes specified in the CMIP
request and the attributes obtained from the reference
object do not provide attribute values for all of the
mandatory attributes for the entry specified by the object
class being instantiated, then the ISO/Internet proxy should
still try to create the object with all the available
attributes.
Chang Page 16
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
If the actual creation process based on the available but
incomplete attribute list succeeds, the ISO/Internet proxy
should retrieve all the attributes on the newly created
entry since the Internet agent may fill in the missing
attributes with the Internet agent's own default values. If
the missing attributes are provided by the agent, the CMIP
create response should include the attributes that were
provided by the Internet agent in its CMIP response.
If the actual creation process based on the available but
incomplete attribute list fails, the ISO/Internet proxy
should send a "missing attribute value" error back to the
ISO/CCITT manager.
See 3.4.1.1. of this memo for checking the existence of an
object.
3.4.5.5. Form the responses
The CMIP M-CREATE response should be formatted and then
should passed to the CMIP service provider.
The managed object instance in the CMIP set response should
use the the distinguished name (DN) specified in the
original CMIP request as a prefix. The set responses for
subordinate objects below the base object in the naming
tree, should contain DN's that are formed from the
concatenation of the DN from the original CMIP request and
the RDN's specifying the table entry deleted.
3.4.6. M-DELETE Service
3.4.6.1. Check the Existence of the Base Object
This operation is the same as described in section 3.4.1.1.
3.4.6.2. Scope and Filter
This operation is the same as described in section 3.4.1.2.
3.4.6.3. Perform the Delete Operation
For all the selected ISO/CCITT object instances, the
following procedures should be taken:
3.4.6.3.1. Name binding
Determine from the name binding if the instance specified in
the request may be deleted. If the name binding does not
allow the specified delete operation, "access denied" error
response should be returned.
3.4.6.3.2. Check the Existence of the Selected Object
Chang Page 17
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
For each selected object, the following steps should be
taken.
If the selected object is a table entry or an SNMP group
with at least one Internet object type (not a pseudo
object), the ISO/Internet proxy should try to retrieve at
least one attribute of the object from the SNMP agent to
verify the existence of the selected object.
If the base object is a pseudo object, the ISO/Internet
proxy should try to retrieve at least one attribute from the
first subordinate object in the MIT that is not a pseudo
object, in order to verify the logical existence of the base
object (pseudo object).
3.4.6.3.3. Perform the Delete Operation
If the object instance specified in the CMIP delete request
exists, the delete operation is performed.
3.4.6.3.4. Form the responses
Format the CMIP M-DELETE response with the appropriate
attribute list or delete list error. Once the M-DELETE
response has been formatted, it should be passed to the CMIP
service provider.
The managed object instance in the CMIP delete response
should use the the distinguished name (DN) specified in the
original CMIP request as a prefix. The delete responses for
subordinate objects below the base object in the naming
tree, should contain DN's that are formed from the
concatenation of the DN from the original CMIP request and
the RDN's specifying the table entry deleted.
3.5. Management Notification Services
All the SNMP traps should be mapped to CMIP notifications.
Only unconfirmed mode is used since the SNMP traps are not
confirmed.
An SNMP trap is translated to a single CMIP event report.
The following procedures should be used to translate an SNMP
trap to a CMIP event report.
3.5.1. Object Class
The object class parameter in the CMIP event report should
be set to the appropriate object class as defined in the
object class definitions.
3.5.2. Object Instance
Chang Page 18
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
The object instance parameter in the CMIP event report is
determined from information provided in the SNMP trap. The
SNMP trap sender's transport type, transport address, and
network address are used to determine the DN of the proxy
object instance.
3.5.3. Event Time
The event time parameter in the CMIP event report should be
calculated based on the time stamp field in the SNMP trap.
3.5.4. Event Type
The event type parameter in the CMIP event report should be
determined by the generic trap field and enterprise specific
trap field in the SNMP trap.
3.5.5. Event Info
The event type parameter in the CMIP event report should be
determined from a Notification definition.
3.5.6. If any of the translations in the preceding sections
fail, no CMIP event report is produced.
3.6. Common Response Parameter
This memo does not specify a standard translation for the
timestamp value in the CMIP response. However, the
following paragraphs describe two potential implementations
for this translation:
- ISO/Internet proxy's local time
- Internet agent's local time with fixed unknown delta
3.6.1. ISO/Internet Proxy's Local Time
The timestamp value in the CMIP response is set to the time
provided by the ISO/Internet proxy's internal clock when a
request's final SNMP response is received.
3.6.2. Internet agent's local time with fixed unknown delta
The ISO/Internet proxy should query the Internet agent for
"sysUpTime" in addition to the original SNMP variable
binding list in the first SNMP request. The value should be
recorded as the "agent's initial sysUpTime" and the
ISO/Internet proxy's local time should be recorded as
"initial contact time".
Each CMIP request is translated to one or more SNMP requests
by the ISO/Internet proxy to fulfill the CMIP request. If
the last SNMP request for the same CMIP request is an SNMP
get request, the "sysUpTime" should be added into the SNMP
Chang Page 19
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
variable binding list. Otherwise, an extra SNMP get request
is issued with "sysUpTime" as the only element in the
variable binding list. This new "sysUpTime" is called
"agent's current sysUpTime".
The timestamp in the last CMIP response should be calculated
using this formula: "initial contact time" + (agent's
current sysUpTime - agent's initial sysUpTime").
This approach eliminates the inaccuracy caused by network
delay between the ISO/Internet proxy and Internet agent and
gives the ISO/CCITT manager a more accurate time on when an
operation is actually performed by the Internet agent rather
than the time that is processed by the ISO/Internet proxy.
4. CMIP and SNMP Protocol Mapping
To retrieve and modify SNMP entries, the ISO/Internet proxy
is required to perform CMIP and SNMP protocol translation.
A CMIP request is translated to one or more SNMP requests.
SNMP responses are translated to CMIP responses. SNMP traps
are translated to CMIP notifications.
4.1. Management Object Selection - Scoping and filtering
A managed object selection process is described in section
4.2 of this memo. Section 3.2.2 and 3.2.4 state:
3.2.2. If the object class is a multiple instance
object, the first instance (.i.e., the first row in the
table) should be retrieved.
The ISO/Internet proxy would issue SNMP get-next requests to
retrieve the instance information from the table.
Each attribute in the object class is used to form a
variable binding in the variable binding list in the SNMP
request. The attributes in the object class are maintained
by the ISO/Internet proxy locally.
Each attribute in the object class is used as the "name"
field in the variable binding. The ISO/Internet proxy
composes a variable binding list and then encodes an SNMP
get-next request.
3.2.4. If the object instance is a multiple instance
object, retrieve succeeding instances (i.e., the
succeeding rows in the table). If a filter is
specified, apply the filter as specified in 3.2.2.
Repeat this process until all instances of the multiple
instance object (i.e. all rows) have been retrieved.
Chang Page 20
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
The ISO/Internet proxy should issue SNMP get-next requests
to retrieve the succeeding object instance. The variable
binding list is the same as the the variable binding list in
the previous SNMP get response (that resulted from the
previous get-next request).
If the SNMP error, noSuchName, occurs when an attribute is
queried as part of a filter evaluation, then the filterItem
will be evaluated as FALSE.
4.2. Check for Existence of the Object to be Created
Section 3.4.1.1 of this memo:
If the base object is a table entry or an SNMP group
with at least one Internet object type (i.e., not a
pseudo object), the ISO/Internet proxy should try to
retrieve at least one attribute of the base object from
the Internet agent to verify the existence of the base
object.
The ISO/Internet proxy should issue an SNMP get request to
retrieve at least one attribute in the base object. The
variable binding is composed using information specified in
the CMIP request.
If the base object is a pseudo object, the ISO/Internet
proxy should try to retrieve at least one attribute
from the first subordinate object in the MIT that is
not a pseudo object, in order to verify the logical
existence of the base object (pseudo object).
The ISO/Internet proxy should issue an SNMP get-next request
is used to retrieve at least one attribute from the first
subordinate object in the naming tree that is not a pseudo
object.
In both of the above cases, a variable binding is needed in
the SNMP request. The variable binding contains "name" and
"value". Only "name" is significant in the SNMP request.
4.2.1 SNMP Entry
If the base object is an "SNMP entry", the first component
in the "name" field is taken from any attribute in the
object class. The object class is specified in the CMIP
request and the attribute is obtained from the object class
definition by the ISO/Internet proxy using local means. The
process specified in section 5.8 of this memo could be used
to form the variable binding. Once the variable binding has
been formed, an SNMP get request is issued to get the
attribute value, which will validate the existence of the
base object.
Chang Page 21
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
4.2.2. Pseudo Entry
If the base object is a "pseudo entry", there is no SNMP
entry that maps to this ISO/CCITT entry. Therefore the
first SNMP subordinate entry of this base object is queried
to verify the existence of this base object.
The "name" field is taken from the object class object
identifier directly to form the SNMP get-next request.
If the "name" field in the variable binding in the SNMP get
response contains the same object identifier prefix as the
request, the ISO/Internet proxy can conclude that this
pseudo entry should exist. If the "name" field in the SNMP
request and the "name" field in the SNMP response does not
have the same object identifier prefix, the ISO/Internet
proxy can conclude that the pseudo entry does not exist.
The same object identifier prefix means that the "name"
field, which is a object identifier, in the response should
contain the same object identifier as the one in the request
with one or more additional digits
If SNMP "no such name" error is received, the ISO/Internet
proxy can conclude that the pseudo entry does not exist.
Any other error should refer to section 5.9 of this memo.
Note. The same method can also be used to verify the
existence of an SNMP "group" entry.
4.3. Create With Referenced Object
An SNMP get request should be issued to obtain the
attributes in the referenced object.
Each attribute in the object class forms a variable binding
in the variable binding list in the SNMP request. The
attributes in the object class id maintained by the
ISO/Internet proxy locally.
For each attribute in the object class, the process
described in section 5.8 of this memo should be taken to
form the variable binding. The ISO/Internet then compose a
variable binding list.
If SNMP "no such name" error is received, the ISO/Internet
proxy can conclude that the pseudo entry does not exist.
Any other error should refer to section 5.9 of this memo..
4.4. Perform the Get Operation
For each selected attribute, the ISO/Internet proxy should
use the process defined in 5.8 of this memo to form the
variable binding. The ISO/Internet proxy should then form
Chang Page 22
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
the variable binding list and then issue an SNMP get request
to perform the get operation.
4.5. Perform the Set Operation
For each attributes, the ISO/Internet proxy should use the
process defined in section 5.8 of this memo to form the
variable binding. The "value" field will be taken from the
modification list. The ISO/Internet proxy should then form
the variable binding list and then issue an SNMP set request
to perform the set operation.
4.6. Perform the Create Operation
For each available attributes, the combination of the
attributes specified in the CMIP request and the attributes
obtained from the reference object, the ISO/Internet proxy
should use the process defined in section 5.8 of this memo
to form the variable binding list. The "value" field will
be taken from either the CMIP request or the referenced
object.
4.7. Perform the Delete Operation
The ISO/Internet proxy needs to determine the attribute type
and attribute value that indicates an entry has been
deleted. This information is maintained locally by the
ISO/Internet proxy.
Each object selected by the CMIP delete request is
translated to a variable binding. All of the selected
objects could be translated into variable bindings within
one SNMP set request. If the request is too big, the
ISO/Internet proxy should divide the request to smaller
requests.
For each to-be-deleted object, the ISO/Internet proxy should
use the process defined in section 5.8 of this memo to form
the variable binding. The "value" field will be filled in
using the attribute value that indicates an entry has been
deleted.
4.8. Form a Variable Binding
The variable binding contains two fields: "name" and
"value". The "name" field is composed by the ISO/Internet
proxy based on its object class, attribute, and a RDN.
The "name" field in the variable binding is formed from the
concatenation of two components.
The first component in the "name" field is the attribute's
object identifier.
Chang Page 23
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
There are two cases for the second component in the "name"
field.
If the object class is a "single instance" object, (i.e., an
SNMP group or an SNMP table), the digit "0" is used for the
second component.
If the object class is a "multiple instance" object (i.e., a
table entry), and if a RDN is supplied, the Internet object
instance might be derived from the RDN. An RDN consists of
an attribute type and an attribute value. The attribute
value of the RDN has two parts. The first part of the value
is the object class object identifier. The second part of
the value is the Internet object instance. This second part
of the value is used as the second component in the "name"
field of the variable binding.
Example 1: single instance object
Input:Object class: system
Attribute: sysName
attribute value in the RDN: system
The SNMP variable binding: sysName.0
Example 2: multiple instance object
Input:Object class: ipRouteEntry
Attribute: ipRouteDest
attribute value in the RDN: ipRouteEntry.192.22.83.97
The SNMP variable binding: ipRouteDest.192.22.83.97
4.9. SNMP error to CMIP error mapping
SNMP error responses received by the ISO/Internet proxy are
translated to CMIP error responses and sent back to the
ISO/CCITT manager. The sections that follow list the SNMP
errors that could be received, and describes which CMIP
error responses they will be translated to.
4.9.1. tooBig
If the SNMP error, tooBig, is received, the ISO/Internet
proxy should try to break the SNMP request to smaller
requests and resend the requests. If it is not feasible to
break the request to any smaller request, and this error
occurs, the CMIP error response, "Resource limitation",
should be returned to the ISO/CCITT manager.
4.9.2. noSuchName
Chang Page 24
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
If the SNMP error, noSuchName, occurs when an attribute is
queried as part of a filter evaluation, then the filterItem
will be evaluated as FALSE.
In order to check if an object exists, all the object
class's attributes should be queried until at least one
attribute's existence is verified. if none of the
attributes exist, and the object is the base object, then a
"NoSuchObjectInstance" CMIP error response should be
returned.
If the object exists and the SNMP error, noSuchName, occurs
when attempting to modify an attribute while processing the
attribute list, a "No such attribute" CMIP error response
should be returned to the ISO/CCITT manager.
If the ISO/Internet proxy maintains correct schema
information and the SNMP agent is a conformant agent, an
Internet object's attributes should all exist or not exist.
In order to make the ISO/Internet proxy a practical
solution, the preceding error situation is included in order
to deal with a non-conformant Internet agent.
4.9.3. badValue
If the SNMP error, badValue, is returned for an SNMP get
request, then a "processing failure" CMIP error response
should be returned to the CMIP manager. In the
ProcessingFailure parameter of the CMIP error response, the
errorId should be snmpBadValue, and the errorInfo should be
the variable binding identified by the error-index.
If the badValue error occurs during an SNMP set request to
fulfil a CMIP delete request, a "processing failure" CMIP
error response should be returned. In the ProcessingFailure
parameter, the errorId should be canNotDelete and the
errorInfo should be the variable binding that is identified
by the error-index.
4.9.4. readOnly
If the SNMP error, readOnly, occurs when checking for the
existence of a base object, a "processing failure" CMIP
error response should be returned to the ISO/CCITT manager.
In the ProcessingFailure parameter of the CMIP error
response, the errorId should be snmpReadOnly, and the
errorInfo should be the variable binding identified by the
error-index.
If the readOnly error occurs when deleting the object, then
the deleteErrorInfo in the delete response should be set to
"access denied".
4.9.5. genErr
Chang Page 25
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
If the SNMP error, genErr, occurs, the "ProcessingFailure"
CMIP error response should be returned to ISO/CCITT manager.
If the entry exists, scoping continues; otherwise, scoping
terminates. In the ProcessingFailure parameter of the CMIP
error response, the errorId should be snmpGenErr.
5. CMIP Processing Failure
There are many error scenarios in which the error can not be
mapped to a specific CMIP error. In this case, the
"processing failure" CMIP error response should be reported
back to the ISO/CCITT manager. In order to provide the
ISO/CCITT manager a better description of the error, the
specificErrorInfo field in ProcessingFailure is used to
record the cause of the problem.
The following object identifiers are defined:
errors OBJECT IDENTIFIER :: { oim 11 }
snmpTooBig OBJECT IDENTIFIER :: { errors 0 }
snmpBadValue OBJECT IDENTIFIER :: { errors 1 }
snmpReadOnly OBJECT IDENTIFIER :: { errors 2 }
snmpGenErr OBJECT IDENTIFIER :: { errors 3 }
noResponse OBJECT IDENTIFIER :: { errors 4 }
canNotDelete OBJECT IDENTIFIER :: { errors 5 }
notImplemented OBJECT IDENTIFIER :: { errors 6 }
For errorId snmpTooBig, the errInfo is defined as
VarBindList.
For errorId snmpBadValue, the errInfo is defined as VarBind.
For errorId snmpReadOnly, the errInfo is defined as OBJECT
IDENTIFIER.
For errorId canNotDelete, the errInfo is defined as VarBind.
For errorId notImplemented, the errInfo is defined as
INTEGER {
filter(0),
scope(1),
transport(2),
AuthenticationProtocol(6),
PrivacyProtocol(7)
}
6. Functional Units
A ISO/Internet proxy implementation that claims conformance
to this memo must state the functional units that it
supports. Two functional units are defined:
a) a minimum proxy functional unit; and
Chang Page 26
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
b) an additional scoping functional unit.
The minimum proxy functional unit requires the support of
create operations, scoped get operations, base-object-only
set operations, base-object-only delete operations, and
notifications.
The additional scoping functional unit requires the support
of scoped set operations and scoped delete operations.
This memo assigns the following object identifier:
{ cmipsxmpProxy aAssociateUserInfo(7) }
Editor's note: cmipsxmpProxy is specified in [OIMTRANSMIB].
as a value of ASN.1 type FunctionalUnitPackageId defined in
CCITT Rec. X.701 | ISO/IEC 10040 to use for negotiating the
following functional units:
0 minimum proxy functional unit; and
1 additional scoping functional unit.
Where the above number identifies the bit position in the
BIT STRING assigned to the functional units.
Editor's note: Is functional unit appropriate? Maybe some
sort of compliance sentence is more appropriate? Is this
section needed at all? Suggestions?
7. Abbreviations
CMIP: Common Management Information Protocol
MIB: Management Information Base
DN: Distinguished Name
RDN Relative Distinguished Name
SNMP: Simple Network Management Information Protocol
8. Acknowledgements
The following individuals provided valuable comments on the
memo prior to its initial distribution.
Dean Voiss, NetLabs
Jon Biggar, NetLabs
Lee LaBarre, MITRE
Lisa Phifer, Bellcore
Steve Ng, MPR Teltech
References
Chang Page 27
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
[ISO8824] ISO/IEC IS 8824: Information Technology - Open
System Interconnection - Specification of
Abstract Syntax Notation One (ASN.1),1990.
[ISO10165-4] ISO/IEC IS 10165-4: Information Technology -
Open Systems Interconnection - Structure of
Management Information - Part 4: Guidelines for
the Definition of Managed Objects, 1991.
[ISO9595] ISO/IEC IS 9595, Information Technology - Open
Systems Interconnection - Common Management
Information Service Definition, 1991.
[ISO9596-1]ISO/IEC IS 9596-1, Information Technology - Open
Systems Interconnection - Common Management
Information Protocol - Part 1: Specification,
1991.
[RFC1155] RFC1155, M. Rose and K. McCloghrie, Structure
and Identification of Management Information for
TCP/IP-based internets, May 1990.
[RFC1157] RFC 1157, J.D. Case, M.S. Fedor, M.L.
Schoffstall, C. Davin, Simple Network Management
Protocol (SNMP), May 1990.
[RFC1351] RFC 1351, Davin, J., Galvin, J., and K.
McCloghrie, "SNMP Administrative Model", MIT
Laboratory for Computer Science, Trusted
Information Systems, Inc., Hughes LAN Systems,
Inc., July 1992.
[RFC1352] RFC 1352, Galvin, J., McCloghrie, K., and J.
Davin, Trusted Information Systems, Inc., Hughes
LAN Systems, Inc., MIT Laboratory for Computer
Science, July 1992.
[RFC1353] RFC 1353, McCloghrie, K., Davin, J., and J.
Galvin, "Definitions of Managed Objects for
Administration of SNMP Parties", Hughes LAN
Systems, Inc., MIT Laboratory for Computer
Science, Trusted Information Systems, Inc., July
1992.
[OIMTRANSMIB] Lee LaBarre, ISO and Internet Management
Coexistence (IIMC): Translation of Internet MIBs
for ISO/Internet Proxy. The MITRE Corporation,
September 92.
[OIMPARTY] Lee LaBarre, ISO and Internet Management
Coexistence (IIMC): Proxy MIB for the SNMP Party
MIB. The MITRE Corporation, September 92.
Chang Page 28
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
[OIMMIB-II]Lee LaBarre, ISO and Internet Management
Coexistence (IIMC): Proxy Management Information
Base II for TCP/IP Networks. The MITRE
Corporation, September 92.
[IIMCOMIBTRANS] O. Newnan, ISO/CCITT and Internet Management
Coexistence: Translation of ISO/CCITT GDMO MIBs
to Internet MIBs, October 1992.
Appendix A: CMIP to RFC 1157 Agent proxy
The philosophy of implementation for either a ISO/Internet
proxy that acts as a proxy for an RFC 1157 Internet agent,
or for a proxy for a secure Internet agent, is quite
similar. The following sections describe the differences
between the two types of proxy agents.
1. SNMP Protocol Selection
The partyauthprotocol attribute in the selected SNMP party
object indicates which SNMP protocol is to be used. If the
community protocol is selected, the ISO/Internet proxy
encodes the SNMP message based on the definition in RFC
1157. If the md5 authentication protocol is selected, the
ISO/Internet proxy encodes the SNMP message based on the
definition in the secure SNMP memos.
2. Security Protocol Selection
If the attribute, partyAuthProtocol, indicates that the
community protocol is to be used, the attribute,
partyAuthPriv, provides the value for the community string
that is to be used to form the SNMP request.
If the attribute, partyAuthProtocol, indicates that the md5
authentication protocol is to be used, the SNMP message
should be encoded using the appropriate authentication and
encryption mechanisms based on the definition in the secure
SNMP memos.
3. Internet agent Address Resolution
For each of the CMIP requests received by the ISO/Internet
proxy, an SNMP source party and a destination party are
selected based on the DN and access control fields in the
CMIP request. The SNMP party object selected is the source
party object contains the Internet agent's address
information in the following two attributes: partyTDomain;
and partyTaddr.
The attribute, partyTDomain, specifies the transport
mechanism. The attribute, partyTAddr, specifies the
Chang Page 29
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
transport and network address. The address format of the
partyTaddr is determined from the value of the partyTDomain
attribute.
4. readyOnly error
If the Internet agent that the ISO/Internet proxy represents
is an RFC 1157 community-based Internet agent, the the SNMP
readOnly error should never be received by the proxy. If
this error is received, a "processing failure" CMIP error
response should be returned to the ISO/CCITT manager. In
the ProcessingFailure parameter, the errorId should be
snmpReadOnly and the errorInfo should be the variable
binding that is identified by the error-index.
Appendix B: Example Operation
Operation: CMIP get request
Object class: ip
Object instance:{cmipsxmpProxyId = "NetLabs" }
{internetClassId = ip }
Scope: 2nd level down
Filter: ipRouteType == indirect
Attribute id list: ipRouteDest
Example SNMP ipRouteEntries:
ipRouteDest ipRouteType Other object types
----------- ----------- ------------------
192.95.93.1 direct
192.95.93.2 indirect
192.95.93.3 invalid
192.95.93.4 other
192.95.93.5 indirect
(end of the table)
The following sections show an example of how the
ISO/Internet proxy fulfills the above CMIP get request based
on the example SNMP ipRouteEntries.
1. Check the existence of the base object:
The ISO/Internet proxy issues a SNMP get next request.
GetNextRequest { ip }
GetResponse { ipForwarding = 1 }
If the get is successful, the ISO/Internet proxy would have
verified that the base object exists.
2. Managed object selection
Chang Page 30
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
Based on the name binding definition, the following object
classes are found in the "object class group":
a) ipAddrEntry
b) ipRouteEntry
c) ipNetToMediaEntry
For each object in the "object class group", the object
instances may be retrieved via SNMP get next requests.
a) ipAddrEntry: The object class definition for this
object class does not contain the attribute specified
in the filter (ipRouteType), therefore the ISO/Internet
proxy will conclude that there is no object instances
with ipAddrEntry object class in the scope.
b) ipRouteEntry: The object class definition for this
object class contains the attribute specified in the
filter (ipRouteType), therefore the ISO/Internet proxy
would issue SNMP get next request to retrieve the
object instances. The SNMP requests issued and the
responses received would be as follows:
GetNextRequest {ipRouteDest, ipRouteType}
GetResponse {ipRouteDest.192.94.93.1 = 192.94.93.1,
ipRouteType.192.94.93.1 = direct}
GetNextRequest {ipRouteDest.192.94.93.1,
ipRouteType.192.94.93.1}
GetResponse {ipRouteDest.192.94.93.2 = 192.94.93.2,
ipRouteType.192.94.93.2 = indirect}
GetNextRequest {ipRouteDest.192.94.93.2,
ipRouteType.192.94.93.2}
GetResponse {ipRouteDest.192.94.93.3 = 192.94.93.3,
ipRouteType.192.94.93.3 = invalid}
GetNextRequest {ipRouteDest.192.94.93.3,
ipRouteType.192.94.93.3}
GetResponse {ipRouteDest.192.94.93.4 = 192.94.93.4,
ipRouteType.192.94.93.4 = other}
GetNextRequest {ipRouteDest.192.94.93.4,
ipRouteType.192.94.93.4}
GetResponse {ipRouteDest.192.94.93.5 = 192.94.93.5,
ipRouteType.192.94.93.5 = indirect}
GetNextRequest {ipRouteDest.192.94.93.5,
ipRouteType.192.94.93.5}
GetResponse {ipRouteIfIndex = 5,
ipRouteProto = 1}
c) ipNetToMediaEntry: The object class definition for
this object class does not contain the attribute
Chang Page 31
Draft ISO/CCITT to Internet Management Proxy 10/9/1992
specified in the filter (ipRouteType), therefore the
ISO/Internet proxy will conclude that there is no
object instances with ipNetToMediaEntry object class in
the scope.
There are a set of five object instances in the scope. After
the filter is applied to these five object instances, there
are only two object instances left on which the get
operation is performed.
3. Form the response
The following CMIP responses should be formed and sent back
to the ISO/CCITT manager
CMIP get link reply:
Object class: ipRouteEntry
Object instance:{cmipsxmpProxyId = "NetLabs" }
{internetClassId = ip }
{internetClassId = ipRouteTable }
{internetClassId = ipRouteEntry.192.94.93.2 }
Attribute list: ipRouteDest = 192.4.93.2
CMIP get link reply:
Object class: ipRouteEntry
Object instance:{cmipsxmpProxyId = "NetLabs" }
{internetClassId = ip }
{internetClassId = ipRouteTable }
{internetClassId = ipRouteEntry.192.94.93.5 }
Attribute list: ipRouteDest = 192.4.93.5
Final Empty CMIS M-GET response
- INTERNET DRAFT Expires April 23, 1993 -
Chang Page 32